In the current implementation of secure Internet Protocol (IP) tunnel, tunnel communication (e.g. liveliness check) packets traverse all the layers of TCP/IP stack en route to a destination server. In such a case, the routing table entries at the IP layer partially control the communication channel. That is, any inappropriate route entry in the routing table is sufficient enough to change the packet path. Sometimes this might lead to the packet cycling within the host machine, session time outs, etc.
In a scenario where the routing table contains an entry for a Virtual Private Network (VPN) server that is destined to another network entity, the secure IP tunnel packet that is destined to that sever would never reach the VPN server due to the route entry. In a worse case scenario, where the routing table includes a route for the VPN server network routed to the virtual network interface (e.g. Network Tap (TAP interface)), the tunnel packet generated by the tunnel application is directed to a virtual interface, which in turn gives the packet back to the tunnel application residing in the host itself. So, the packet goes circling the path in the same host.
Secondly, all the packets that are processed and encrypted by a secure IP tunnel client are routed using the routing table entries, which are not needed. This includes application data (HTTP, FTP, Telnet, etc.) generated by the client.
A VPN client is said to be connected to the server when a secure IP tunnel connection gets established between the client and the server, and the client host machine is updated with the network routes based on the user access control policies. Every packet destined to the network in the user access control policies is routed to a virtual interface (e.g. Tap and/or Network TUNnel (TUN) interface) by the IP layer. All the packets coming from TAP/TUN interface are picked up by Secure IP tunnel client for policy validation and encryption. The destination IP address for the encrypted packet will be the VPN server's IP address. Once policy validation and encryption are performed, the packet is sent to TCP stack again and routed through the physical network. In this process, packets are obviously checked against the routing table entries for routing. Apart from the application data packets, all the tunnel communication packets also get encrypted and traverse all the layers of TCP/IP network stack.
With a faulty traffic policy that allows/denies a particular application data to public network destination that includes the VPN server network, the Open VPN (OpenVPN) tunnel communication fails. The user session gets terminated after a limited number of attempts. This is because the tunnel communication (e.g. liveliness check, tunnel negotiation) packets are routed to the TAP/TUN interface due to a subnet route entry. The packet is then routed to the OpenVPN application for policy validation and encryption. Here, since there may be no policy to allow traffic destined to VPN server's IP address:port combination, the packet is dropped. After a limited number of attempts for such a communication, the session is terminated. Other user access control policies fail due to the communication failure as well. An application data packet, which reaches OpenVPN application from TAP/TUN interface, gets encrypted. The destination IP address of every encrypted packet is the server's IP address. Now, the packet is handed to the TCP/IP stack. At the IP layer, since the routing table contains the destination network routed to TAP/TUN interface address, the packet is directed to TAP interface and is again forwarded to tunnel client application. This continues until tunnel termination occurs and thus the client connection aborts after few retries.
Thus, what are needed are improved techniques for packet processing that removes IP layer routing dependencies.